公司替工程師開好企業版 AI 帳號，治理其實還沒開始。
帳號只解決「誰可以登入」。它沒回答哪些程式碼能送進模型、MCP 可以用誰的身分碰內部系統，也沒決定 agent 改完 repository 之後，最後由誰按下 merge。
這幾個問題如果沒有先講清楚，團隊很容易得到一套表面上集中管理、實際上責任四散的 AI 工作流。出了事，大家才發現 prompt、token、工具呼叫與 PR 各有一套紀錄，彼此還串不起來。
iThome 的 2026 CIO&CISO 調查報導指出，32% 受訪台灣大型企業計畫採用 AI 增強軟體工程；Agentic AI 的採用比例也從 17% 升到 32%。調查範圍是受訪的大型企業，採用率本身也不等於準備度。不過，問題確實已經從「工程師可不可以用 AI」往「怎麼放進正式流程」移動。
個人拿 AI 補一段測試，風險通常停在自己的工作區。Agent 一旦能讀 issue、查內部資料、修改檔案、跑指令，再替你開 PR，治理範圍就會一路擴到工具權限、執行環境、持久狀態與驗收流程。
我會把這件事拆成四條責任邊界：資料、身分與稽核、執行權限、驗收責任。這套操作框架不冒充法遵標準，它的用途是讓工程團隊有辦法把責任談清楚。
「公司用企業帳號」不是資料政策。資料政策得寫到這麼細：哪一類資料，可以透過哪個入口，交給哪一種模型處理，之後會留下哪些紀錄。
原始碼、客戶資料、production log、issue 與內部文件不該共用一句模糊的「禁止上傳機密」。團隊至少要逐類確認傳輸路徑、保留期限、是否用於訓練、誰能查閱 request log，以及 proxy 會不會另外保存內容。規則也要落到 agent 的工具上，否則使用者不能貼客戶資料，MCP 卻可以直接把同一筆資料查回來，禁令只是貼在門口的告示。
地端模型也不是免檢查。模型在公司裡執行，不等於 log、向量資料庫、備份與管理介面都留在同一個信任範圍。部署位置只回答了其中一題。
最省事的串法，通常是把開發者的個人 token 塞給 agent。這也是日後最難說清楚的串法。
Agent 應該使用可識別、可撤銷、權限受限的工作身分。每次工具呼叫至少要能倒查委派者、session、目的、碰過的資源、核准紀錄與結果。這樣發現一筆異常寫入時，團隊才能回答它從哪個任務開始，而不是只看到「某位工程師的帳號做了變更」。
撤權也得實測。員工離職或任務取消後，既有 session、快取憑證和背景程序是否同時失效？如果舊 token 還能呼叫 GitLab、Jira 或內部資料庫，IAM 畫面上的停用只完成了一半。
MCP 解決的是工具怎麼接，不會替團隊決定工具該不該被呼叫。連線協定不是授權政策。
很多導入案一開始只分「可用」和「不可用」，對 agent 來說太粗了。讀文件、提出 patch、寫入 sandbox、建立 PR、合併與部署，風險完全不同，應該有不同的權限與核准方式。
Google 在 Gemini API Managed Agents 中提供工具使用、隔離 Linux 環境內的程式執行，以及保留檔案與狀態後續接環境的能力。這類設計很實用，也把治理範圍說得很明白：當一個 session 能留下狀態，安全邊界就包含檔案、程序、憑證注入與清理時機，不能只檢查送給模型的文字。
實務上可以先把權限切成階梯：read-only 任務只能查詢；建議模式只回傳 diff；sandbox write 可以改隔離分支，但碰不到 secrets 與 protected branch；會造成外部副作用的工具呼叫，則要求明確核准。不要因為前一級運作順利，就直接把 production 權限一起打開。
如果同一個 agent 產生 patch、解讀測試結果、做 code review，最後還能合併，表面上流程走完了，四個步驟卻都依賴同一個信任來源。
驗收責任要落在人與證據上。哪些測試必須通過、哪類變更需要指定 reviewer、CI 紀錄保存在哪裡、風險升級後由誰處理，都應該寫進 repository 或平台規則。AI review 可以提供另一個觀察角度，但不能因為語氣很有把握，就取代 PR owner。
這裡也要避免一個常見假象：測試顯示綠燈，不代表測的是對的東西。Agent 若同時改了實作與測試，reviewer 得確認 acceptance criteria 沒被悄悄改寫。可合併的證據應該來自獨立規則，而不是產生變更的模型自己宣告完成。
我比較相信保守但能持續擴張的做法。先讓 agent 處理非敏感、read-only、結果容易人工抽查的任務；紀錄穩定之後，再開放 sandbox write；最後才接上有副作用的內部工具，而且 approval、撤權與稽核必須先到位。
每升一級，都先故意讓它失敗一次：呼叫禁止的資源、執行途中撤掉 token、讓 session 在工具回傳一半時中斷。團隊要確認系統能停下來、權限真的收得回去，事後也找得到完整路徑。只測 happy path，等於把事故演練留給正式環境。
台灣已有把算力、開發工具、模型服務、微調與評估放進同一工作流的在地方案，包含 TAIDE 與開源模型支援。這讓企業多了一種部署選項，沒有讓四條邊界自動消失。用外部模型、proxy、企業雲或在地平台，都該接受同一套檢查。
成熟的 AI 導入，最後看起來可能有點無聊：權限表、核准紀錄、測試證據、撤權演練。這些細節有人負責之後，agent 才適合進入正式流程。否則一出事，全公司只會一起找當初是誰按了 Enter。
ryanvale
iThome鐵人賽
看影片追技術